Secure Sockets Layer or SSL is a protocol that was developed to securely transmit private messages between a client and a server via the internet or other public network. SSL is the industry-standard method of protecting web communication by using digitally data encryption and server and message authentication codes to maintain message integrity.
SSL connections typically have two phases. The first phase is the SSL session negotiation, which provides a mechanism for client and server authentication and negotiates encryption keys before data is exchanged. The second phase is the SSL application data transfer. In the second phase, SSL encrypts the data traffic to provide data confidentiality and integrity.
When an SSL session starts, client and server authenticate each other and agree on a secret key to be used encrypt the data transfer. This initial series of transactions are the most intensive operation in SSL processing and the most expensive operation in the handshake is the server-side RSA private key decryption of the client pre-master secret. Subsequent data is encrypted and authenticated with keys derived from the master key. A variety of cryptographic algorithms are supported by the SSL protocol. After the exchange of keys, a number of ciphers such as RC2, RC4, IDEA, DES, triple-DES may be used.
The SSL protocol usually operates in conjunction with an application layer protocol such as HTTPS. When a secure URL is found, that is the connection starts with https://, the client opens a TCP connection to port 443, followed by an SSL handshake and data transfer. SSL encrypts the HTTP header and the payload.
One problem with SSL arises because of the high CPU utilization required to perform all of the encryption operations during the SSL handshake. Of the encryption operations, the RSA encryption/decryption is the most expensive. Efficient handling of the encryption operations is particularly important in a data center where a cluster of servers configured for SSL traffic must be able to handle multiple client connections without degrading response to the client. For example, a server that can process ˜9,000 HTTP (clear text) transactions per second at 100% CPU utilization can process only approximately one percent of the clear text transactions when processing HTTPS transactions. Thus, many servers are often dedicated to handle SSL traffic.
Another problem with SSL arises in data center operations handling SSL traffic. This traffic is distributed among a cluster of servers to share the load of incoming client requests and to provide high availability for the requested application. With load balancing, SSL traffic is sent to the load balancer first and then to a server, and the server undertakes the expensive task of decrypting the data. In other instances, the load balancer utilizes a network device, an SSL offloader, to handle the decryption before the load balancer performs the load distribution decision. The network device returns clear text (decrypted) traffic to the load balancer. Unfortunately, if the load balancer distributes clear text traffic to the server cluster, it can be easily monitored by a compromised server or by an attacker who has managed to connect a traffic monitoring device to the data center's VLAN or sub-net.
Yet another problem with SSL traffic is that a network based intrusion detection system or IDS is unable to analyze the SSL encrypted traffic to detect an attack. Other prior art systems attempt to handle SSL traffic by decrypting the traffic, load balancing and then forwarding the traffic to an SSL device for re-encryption but these embodiments rely on IP forwarding for the sequence processing. While effective, these embodiments also require a much more complex configuration which is undesirable, difficult to implement and maintain. In fact, with such prior art implementation, it is necessary to create a plurality of NAT translations of ports and destination IP addresses to create the traffic flow necessary to decrypt, load balance and then re-encrypt the traffic.
To overcome these disadvantages of the prior art, the present invention efficiently handles SSL traffic while off-loading the encryption/decryption process from the servers of a data center. More specifically, a data center provides secure handling of HTTPS traffic using backend SSL decryption and encryption using a load balancer and an SSL offloader. The load balancer detects HTTPS traffic and redirects it to an SSL offloading device for decryption and return to the load balancer. The load balancer then uses the clear text traffic for load balancing purposes before it redirects the traffic back to the SSL offloading device for re-encryption. Thereafter, the re-encrypted traffic is sent to the destination servers in the data center. The present invention sends the decrypted traffic back to the SSL encryption device after having performed the load balancing decision, without having to alter the destination port or other parameters to re-encrypt the traffic. In one embodiment, the combination with the back-end SSL with an intrusion detection system improves security by performing intrusion detection on the decrypted HTTPS traffic.
The present invention provides significant benefit because the load balancer rewrites the destination IP address (as a result of the load balancing decision) and sends traffic back to the SSL offloading device for re-encryption with very a simple configuration on the SSL offloading device. Advantageously, there is no need to maintain a one-to-one mapping of NAT statements on the SSL offloading device. The load balancer may also be configured to rewrite the destination port to a different port to uniquely identifying the traffic sent by the load balancer to the SSL offload device for re-encryption. The foregoing and additional features and advantages of this invention will become apparent from the detailed description and review of the associated drawing figures that follow.